The invention specifically concerns switching systems capable of processing data organised in packets (packet switching). It also concerns the so-called “multiservice” switching systems, i.e., systems that are capable of performing packet switching while also being capable of processing data organised in different transmission formats (circuit switching), typically data organised in time-division multiplexing (TDM) in compliance with the SDH or SONET protocols or even ODU (“Optical Data Unit”).
Here the term “packet” refers to any data set grouping transmit data information according to a pre-established format (called “payload”) and auxiliary data contained e.g. in a packet header. The header specifically contains an indication of the destination of the packet and generally a service quality class. The indication may be an explicit destination address or a “label” representative of that destination. The most common packet formats include the IP (Internet Protocol), MPLS or Ethernet packets that have a variable size and the ATM cells that have a fixed size.
It should be noted that a network comprises multiple nodes interconnected by transmission links. A node is frequently connected to various other nodes and then integrates routing functions to selectively route data carried by signals received from upstream links to other downstream links depending on the respective destinations of the data. Certain nodes have access functions allowing to introduce data in the network and/or to extract data from the network.
To perform a routing function a node is equipped with a switching system or more simply with a “switch”. A switching system comprises multiple input ports connected by upstream links to transmitters of user stations or to other nodes as well as multiple output ports connected by downstream links to receivers of other user stations or other nodes. In general the switching system is intended to route the data flows received by its various input ports selectively depending on their respective destinations to output ports allocated to these destinations.
Conflict management is an essential role of a switching system, i.e. the permanent control of the data routing to ensure that various received data intended for a same output port are directed to that port at different times.
The performance of a system is evaluated on the basis of its bandwidth, i.e. the total bit rate of binary data it is capable of routing on average without data loss.
FIG. 1 gives a schematic representation of a typical switching system structure. This system comprises a switching matrix 1 driven by a central controller 2, a multiplicity of input modules IM1, IM2, IMi, IMn respectively driven by input controllers IC1, IC2, ICi, ICn and a multiplicity of output modules OM1, OM2, OMj, OMn respectively driven by output controllers OC1, OC2, OCi, OCn. The input modules are respectively connected to upstream links via input ports IP1, IP2, IPi, IPn, and the output modules are respectively connected to downstream links via output ports OP1, OP2, OPj, OPn. The input and output modules are also networked with central controller 2 that combines the system's central control functions.
The data to be switched received by input ports IPi are transmitted to the matrix by input modules IMi, and depending on the commands received from central controller 2, the matrix performs a selective routing of these data to output ports OPj via output modules OMj. Each input module IMi or output module OMj also communicates with controller 2 to the exchange signals and control information required for the good execution of the selective routing.
More specifically, each input module IMi acts as a physical interface with the relevant upstream link and comprises devices for memorizing and processing the received data, these devices are designed to temporarily store the data, e.g. in the case of packets by creating and managing packet queues. If various service quality classes (or more simply “service classes”) are provided in the network, multiple queues will be provided and will be allocated to these respective classes.
Typically, each input module is intended to create multiple queues organised in addressee output ports as well as in service classes. Thus, each of these queues contains the stand-by packets intended for a given output port and benefits from a given service class. The queues organised in this way are occasionally called VOQ (or “Virtual Output Queue”).
The management of the queues consists in permanently filling these queues with the new data received and in extracting from these queues the data authorized for transfer to the matrix.
Data transfers between input modules IMi and switching matrix 1 on the one hand and the transfers between the matrix and output modules OMj on the other hand normally occur in successive switching cycles of a constant duration, designated as “transfer duration”. Preferably, the switch shall furthermore be designed in such a way that each input and output module can respectively send and receive a quantity of packets simultaneously with each switching cycle. An input module shall e.g. be provided to create and send with each cycle a data block comprising a packet set, each fixed size block comprising multiple groups of packets respectively associated with the various output modules, each group comprising packets intended for a same output module associated with that group. The size of a group should preferably be modifiable. It can also be subdivided into subgroups associated respectively with multiple channels and/or multiple service classes. A switch of this type is described in greater detail in European Patent Application EP 1549103, published on 29 Jun. 2005.
For the matrix to be able to switch the data transferred in this way, the central controller must specifically know the respective output ports to which these transferred data must be routed by the matrix. This routing information is obtained from the destinations contained in the packet headers and depending on the routing information loaded beforehand in the routing table. The input modules are responsible for elaborating this routing information and for transmitting it to the central controller in addition to the associated packets transferred to the matrix. The controller then considers the routing information associated with the packets in order to be able to route them accordingly.
These control data are usually designated by the term “overhead” and are added to the “useful” information data to be switched called “payload”. This aspect is represented in FIG. 1, where the payload and the overhead are symbolised respectively by white rectangles PL and hatched rectangles OH.
Prior to the actual routing operations mentioned above, an essential function of a packet switching system is the mechanism allowing to select during operation at what moments how much data of which queues are authorized to be transferred. This role is usually fulfilled by so-called “schedulers” or “arbiters” intended to perform the selections according to predefined rules.
To identify the data to be selected, the arbiters execute an arbitration algorithm intended to optimize the data transfer according to the selected criteria. Amongst possible other criteria the following conditions must at least be met:
avoid conflicts, as stated above;
authorise the input modules to transfer per cycle quantities of data compatible with the maximum transfer capacities between each input module and the matrix on the one hand and between the matrix and each output module on the other hand.
Moreover, a good arbitration mechanism must also meet the following additional conditions:
make stand-by packet choices with a degree of “equity”, i.e. handle all the packets of a same service class in an equivalent manner in terms of average transfer time measured on an as short as possible time frame, whatever the input ports and/or output ports via which they transit, e.g. by taking into account the arrival sequence of the packets to be switched;
allocate differentiated priorities to the packets to be extracted from the queues depending on their respective service classes;
contribute towards optimizing the use of the switch resources, i.e. maximize its bandwidth.
To implement an arbitration mechanism, a centralised realisation can be considered, i.e. provide a hardware and/or software subassembly, hereafter called “arbitration unit” in central controller 2, capable of executing a selected arbitration algorithm. This arbitration unit communicates with the input and/or output modules to receive from the latter all the information required to execute the algorithm and to give them the resulting arbitration decisions.
To this end the input modules each dialogue with the arbitration unit according to the following general diagram. At successive times each input module sends the arbitration units requests informing it of the filling status of its queues. Depending on the requests received from all the input modules, the arbitration unit determines the queues to be transferred to the matrix according to the retained criteria and subsequently informs all the input modules by means of grant messages. Depending on the grant messages it receives each input module updates its queues by performing the corresponding data transfers to the switching matrix.
This centralised realisation, however, presents the inconvenience of being complex and of requiring many exchanges of information, more specifically when the number of input and output ports becomes high. Indeed, the arbitration unit must have processing resources that are sufficiently fast to periodically consider the availability statuses of all the output modules, the statuses of all the queues of all the input modules, and respond by giving the input modules the grant information related to all the queues.
The problem becomes worse if the output modules are each foreseen to manage multiple output channels sharing the same output port.
For instance, a switching system to be currently installed in the optical backbone networks should typically comply with the following technical specifications:
simultaneously process packet and “TDM” traffic;
manage a number of hundreds of channels per output port;
take into account thousands of queues in each input module.